GH-6792: Add headers mapping to JMS channels#10838
Conversation
cppwfs
left a comment
There was a problem hiding this comment.
Great work. Just a couple of nitpicks!
| if (!(converter instanceof MessagingMessageConverter)) { | ||
| messageToSend = getMessageBuilderFactory() | ||
| .fromMessage(messageToSend) | ||
| .copyHeadersIfAbsent(this.headerMapper.toHeaders(message)) |
There was a problem hiding this comment.
Would a user want the original header overwritten? Is this an option we want to add?
There was a problem hiding this comment.
Yeah...
First of all I don't want to expose headers manipulation options from these channels at all.
And secondly, I followed exactly same logic as MessagingMessageConverter.
This our logic here is to mimic that converter when Message is deserialized as is without any JMS headers.
If header is present there in the message, then it is indeed end-user preference.
If something else should be done, the custom MessageConverter is welcome.
Just not header mapping from the channel configuration.
Fixes: spring-projects#6792 Currently, by default `AbstractJmsChannel` implementations use Java serialization for storing `Message<?>` instance into JMS destination. The deserialized message is produced from the channel as is. There might be use-cases when some JMS properties could be useful in downstream flows. * Add `DefaultJmsHeaderMapper` into the `AbstractJmsChannel` as a conditional logic to map headers to/from JMS when `jmsTemplate.getMessageConverter()` is not a `MessagingMessageConverter`. Otherwise, then conversion of the message and header mapping is done in that converter * Refactor logic in the `AbstractJmsChannel` to common API * Fix Nullability formatting in the `PollableJmsChannel` * Use lambda style for `MessageListener` in the `SubscribableJmsChannel` instead of inner extra class * Ensure in the `PollableJmsChannelTests` and `SubscribableJmsChannelTests` that header mapper does it job * Fix `JmsChannelParserTests` to not assert on the `messageBuilderFactory` since now a `MessageListener` in the `SubscribableJmsChannel` is a direct method of the class * Fix `JmsChannelHistoryTests` verification according to a new internal logic of the `AbstractJmsChannel` * Document new feature in the `jms.adoc` and `whats-new.adoc` # Conflicts: # src/reference/antora/modules/ROOT/pages/whats-new.adoc
* Use lambda-based `logger.debug()` in the `PollableJmsChannel` instead of `if (logger.isDebugEnabled()) {`:
the `message` variable is now effectively `final`
* Remove redundant null checks from the `SubscribableJmsChannel`
* Add more header tests into the `PollableJmsChannelTests` & `SubscribableJmsChannelTests`
* Clean up `JmsChannelParserTests` and verify the `messageBuilderFactory` settings
cppwfs
left a comment
There was a problem hiding this comment.
Love the cleanup above and beyond what I requested. This looks great!
LGTM!
Fixes: #6792
Currently, by default
AbstractJmsChannelimplementations use Java serialization for storingMessage<?>instance into JMS destination. The deserialized message is produced from the channel as is. There might be use-cases when some JMS properties could be useful in downstream flows.DefaultJmsHeaderMapperinto theAbstractJmsChannelas a conditional logic to map headers to/from JMS whenjmsTemplate.getMessageConverter()is not aMessagingMessageConverter. Otherwise, then conversion of the message and header mapping is done in that converterAbstractJmsChannelto common APIPollableJmsChannelMessageListenerin theSubscribableJmsChannelinstead of inner extra classPollableJmsChannelTestsandSubscribableJmsChannelTeststhat header mapper does it jobJmsChannelParserTeststo not assert on themessageBuilderFactorysince now aMessageListenerin theSubscribableJmsChannelis a direct method of the classJmsChannelHistoryTestsverification according to a new internal logic of theAbstractJmsChanneljms.adocandwhats-new.adoc